Single Blog

Me parece muy gracioso ver en la red cómo la gente habla constantemente y a menudo de forma inapropiada sobre la computación en la nube, tanto positiva como negativamente. Todo el mundo «dispara» su propia opinión llamándose a sí mismo un experto en esto o aquello.

Como sugiere el título, este es un nuevo evento «desastroso» para la computación en la nube. Y siento que es mi deber analizar el caso y responder a todos aquellos que solo han sido capaces de demonizar el «cloud computing» como si fuera algo que se pueda señalar.

Les recuerdo a la mayoría que la computación en la nube es un paradigma no una tecnología, les recuerdo que puede ser pública y privada, para aquellos que la han olvidado o nunca han tenido la oportunidad de leer una definición oficial.

Evento

Vayamos a lo que sucedió esta vez, al menos hasta donde sabemos.

Una tormenta muy fuerte azotó Estados Unidos el 30 de junio en el área de Virginia, causando al menos 12 muertes, quién sabe cuántos heridos, cuántos se quedaron sin hogar. También se sabe que 2 millones de personas en toda la zona llevan mucho tiempo sin electricidad, y los técnicos se movilizaron de inmediato para tratar de restablecer la energía lo más rápido posible, con el fin de evitar que el calor récord en esa zona aumente el número de muertes debido al mal funcionamiento de los aires acondicionados.

En Virginia existen los centros de datos de Amazon Web Services, esta es la región histórica de AWS, la primera y también la «por defecto» de las APIs de gestión, es decir, si el cliente no cambia de región siempre y únicamente utilizará los recursos de esta zona (basta con añadir –region en el caso de la API Tool o hacer una set_region si usamos el SDK de php o quizás más fácilmente con la Management Console), mientras que AWS se distribuye por todo el mundo (EE. UU., UE, ASIA, Japón, América del Sur) con muchos centros de datos.

Uno de estos centros de datos se ha quedado sin energía, según Amazon. (porque AWS hace público el estado de todos sus servicios en todas las regiones).

Sin embargo, muchos de los servicios de muchos clientes estaban presentes en esta región y se encontraban fuera de línea de un momento a otro. El caso causó sensación porque en esta ocasión cayeron dos grandes portales sociales muy de moda, Instagram y Pinterest (también NetFlix), que permanecieron desconectados durante unas horas.

Pero me pregunto cuántos otros centros de datos menos conocidos con alojamiento de estilo antiguo han corrido la misma suerte.

Fue un evento extremo (probablemente por la forma en que va el clima de nuestro planeta, no será el último),

AWS es el primer y más grande proveedor de nube, el más extendido, el más utilizado, el que tiene mayor presencia de sitios y portales con un tráfico considerable, por lo tanto, es más probable que sea notado en la red por una amplia audiencia, digamos que está muy bajo escrutinio.

El 21 de abril de 2011 la misma región se vio comprometida por un error humano y en mi opinión en este evento radica el verdadero problema al que se tienen que enfrentar las grandes infraestructuras llenas de datos en continuo aumento, el 7 de agosto en cambio los centros de datos irlandeses de AWS y Microsoft se vieron comprometidos por una tormenta eléctrica, en este caso parece que los CC estaban equipados con los mismos sistemas automáticos de respaldo de electricidad, un sistema evidentemente soplado debido a la sobretensión del rayo que caía cerca.

Consideremos los dos casos originados en problemas climáticos extremos sin jugar demasiado con los símbolos entre nubes y tormentas, como han hecho muchos columnistas.

Estamos tratando con centros de datos que han tenido problemas relacionados con los sistemas de respaldo de energía y aquí una breve descripción de cómo funcionan los sistemas de respaldo de energía de un CC está en orden. Un DC generalmente recibe energía eléctrica de un proveedor de energía, esta va directamente al UPS (básicamente paquetes de baterías), luego de ahí pasa a las salas de servidores llenas de racks donde se encuentran los equipos de red, los servidores y el almacenamiento.

Un pequeño paréntesis de GreenIT. Alrededor del 30% de la energía se pierde en la transición de corriente alterna a corriente continua (UPS) y de corriente continua a corriente alterna a corriente alterna a corriente alterna, mientras que cada dispositivo convierte internamente la energía eléctrica en corriente continua. Este es uno de los varios puntos que hemos planteado en nuestro proyecto Make The Cloud Green.

Por lo tanto, existen sistemas totalmente automáticos y confiables que intervienen estabilizando la electricidad a las salas de servidores, es decir, si no hay energía en la fuente, el equipo la toma de los grupos UPS. Obviamente, estos están calibrados para soportar la carga completa unas pocas decenas de minutos, por lo que cada CC que se precie es alimentado por más de un grupo de generadores que siempre entran en funcionamiento automáticamente si el cuerpo de energía ya no suministra energía. Por lo general, estas unidades, generalmente compuestas por motores diésel, tardan muy pocos minutos en arrancar, por lo que el funcionamiento de un CC debe estar garantizado durante muchas horas, es decir, hasta el final del combustible.

Otro paréntesis de GreenIT: este caso de un banco alimentado íntegramente por pilas de combustible, es decir, fuera de la red

En general, todos estos dispositivos, que pueden llegar a entrar en funcionamiento, requieren de una monitorización periódica, mantenimiento y pruebas funcionales que dan lugar a simulaciones programadas de eventos catastróficos. Por lo tanto es un error hablar de Cloud Computing Outage , tenemos que centrarnos en el hecho de que los DCs han sido mal diseñados, o no han sido mantenidos o simulados adecuadamente.

O tal vez se debería pedir a AWS que haga públicas las pruebas y los resultados que se hacen a todos los equipos circundantes de los DC, o más bien crear nuevos estándares, nuevas regulaciones relacionadas con la construcción de los DC, hacerlos energéticamente separados de la red, más seguros frente a eventos atmosféricos, por ejemplo veamos este centro de datos construido en Estocolmo en un antiguo búnker nuclear. Otro paréntesis de GreenIT sería calentar las ciudades adyacentes con el calor emitido por los sistemas en lugar de desperdiciar más energía para enfriar los sistemas y más para calentar los hogares. (alguien ya lo hace)

Responsabilidades de software del cliente

Ahora vayamos a lo que subestimaron los clientes que se encontraban fuera de línea. AWS proporciona herramientas de computación en la nube de grado IaaS, proporciona varios centros de datos y proporciona orientación sobre cómo implementar sus propias arquitecturas, al tiempo que hace hincapié en el uso de varios centros de datos para aplicaciones críticas para el negocio. Significa que un Instagram que ha recibido millones de dólares de inversión, que no sabe cómo diseñar la solución apoyándose en más de un centro de datos, está condenado, no la computación en la nube en sí, ni AWS por cómo se ha diseñado la arquitectura SW de Instagram.

AWS proporciona una serie de servicios sobre los que garantiza Fault Tolerance y High Availability y son S3, SimpleDB, Simple Queue Service, Elastic Load Balancing, Elastic IP y también diría Route53 y sobre los que puedes construir tus propios servicios de Alta Disponibilidad, como ya han hecho muchos otros clientes más inteligentes.

Por otro lado, sería muy indecoroso ver a un Proveedor de Nube Pública PaaS y sobre todo SaaS con problemas de Alta Disponibilidad, como sucedió hace algún tiempo por ejemplo con Gmail de Google.

Finalmente, disfrutemos de una lista de los 10 peores casos de Cloud Outage que no se han actualizado hasta ahora.

• Colosal interrupción de la nube n.º 1: Amazon Web Services se va a pique
• Colosal interrupción de la nube n.º 2: el cierre de Sidekick
• Colosal interrupción de la nube n.º 3: Gmail falla
• Colosal apagón en la nube n.º 4: el desastre de Hotmail
• Colosal interrupción de la nube n.º 5: La duplicación de Intuit
• Colosal interrupción de la nube n.º 6: BPOS de Microsoft oops
• Colosal interrupción de la nube n.º 7: El desliz de Salesforce
• Colosal apagón de nubes n.º 8: el terrible día de Terremark
• Colosal interrupción de la nube No. 9: La caída de PayPal
• Colosal interrupción de la nube n.º 10: el año difícil de Rackspace

Ahora, un pequeño consejo para estimular el estándar de construcción de una nueva generación de centros de datos fuera de la red. La NASA lleva meses advirtiendo oficialmente, si no al menos un par de años, de que las tormentas solares no paran de aumentar, alcanzando su punto álgido desde finales de 2012 hasta finales de 2013 y que, según ellas, podrían poner en grave riesgo nuestras infraestructuras digitales con muchos apagones prolongados.